Check every published export subpath loads in Node - #131
Conversation
The published shape was never built in CI - build is tsc only, while the real artifact comes from prepare via rollup - so nothing ever imported what consumers import. That is why #118 reached a release. This spawns a child node per exports subpath and loads the real package specifier, so resolution goes through the exports map exactly as a consumer's does, and reports the actual error per subpath rather than a total. Non-JS entries are existence-checked; importing them would only ever yield ERR_UNKNOWN_FILE_EXTENSION and say nothing about #118. Wired in as a non-blocking job on purpose: it is red today, because it reproduces #118. It becomes blocking once the directory imports and the CSS side-effect imports are both resolved. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| runs-on: ubuntu-latest | ||
| continue-on-error: true | ||
|
|
||
| steps: | ||
| - name: Checkout code | ||
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Setup node | ||
| uses: actions/setup-node@v4 | ||
| with: | ||
| node-version: 23.x | ||
| registry-url: "https://registry.npmjs.org" | ||
|
|
||
| - uses: actions/cache@v4 | ||
| id: yarn-cache | ||
| with: | ||
| path: | | ||
| .yarn/cache | ||
| **/node_modules | ||
| **/.eslintcache | ||
| **/yarn.lock | ||
| key: ${{ runner.os }}-yarn-${{ hashFiles('**/package.json') }} | ||
|
|
||
| - name: Yarn install | ||
| run: yarn | ||
|
|
||
| - name: Build the published artifact | ||
| working-directory: Source | ||
| run: | | ||
| export NODE_OPTIONS="--max-old-space-size=4096" | ||
| yarn run prepare | ||
|
|
||
| - name: Verify published exports | ||
| working-directory: Source | ||
| run: node scripts/verify-exports.mjs |
|
Reviewer context, kept out of the body. Scope. This does not attempt the #118 defect itself — that is structurally coupled to PrimeReact 11 (#107), because What it measures, and the result — see the full table on #118. Headline: 29 checks failed across 21 subpaths; only Design. One child Non-blocking on purpose, at job level rather than step level, so nothing in the new job — including a broken publish build — can gate a merge while the underlying defect is open. A comment in the workflow says when it should become blocking. Deliberately not added to Semver Not verified: the job has not run on a real runner — validated locally and as YAML only. Components tracks no lockfile, so CI may resolve different transitive versions and produce a different failure set. The workflow's |
3 participants
Added